規格是寫給人看的，描述是給生成器用的

昨天那份規格寫得沒問題，但是仔細看完後會有一個問題在於內容的讀者不一樣。

為什麼呢？ 因為寫給人看的規格可以留一點脈絡讓對方自己接，「緊急的定義如下」後面接三個條件，人讀得懂那三個是 or 的關係。但是生成式 AI 不會接脈絡，它會做的事情是把沒明講的部分補成合理的預設值，然後不告訴你它補了什麼。

即使在描述裡提供了參數 AI 也可能不會自動把它填進去，換句話說寫了但沒被採用，是一個已知且預期內的行為不是描述寫壞了。

所以「把規格貼進去」這個動作本身就不成立，規格要先翻譯成一段生成器吃得下的描述，而翻譯過程中會掉的東西，正是你接下來要親手補回去的清單。

描述要寫成什麼形狀

描述流程時有幾個地方特別容易踩坑，而且大多發生在流程還沒有真正建立之前。

第一個就是觸發條件，生成式 AI 得先知道流程從哪裡開始，後面的動作才有地方接上去。然後服務名稱也盡量直接寫出來，Outlook、Teams、SharePoint 該出現就出現。

少了這些資訊，AI 只能根據描述自行判斷該用哪一個連接器。

如果判斷錯誤回到設計畫面之後，最後還是得重新處理連線或動作設定，這些問題看起來像是 AI 沒有理解需求，但很多時候真正的原因其實是前面的描述還不夠具體。

像是處理郵件這四個字，對人來說已經可以理解大概想做什麼，可是放進流程裡幾乎沒有提供多少真正可以執行的資訊。收到哪一種信件要判斷什麼條件，接著執行哪一個動作，最後把結果送到哪裡，這些細節補上之後，一段描述才會開始接近真正的流程。

寫這類描述時還有幾個地方很值得刻意拆開，像是判斷郵件是否緊急並通知組長，閱讀起來很自然但實際放進流程裡已經包含兩件事，一個是判斷，一個是通知。

拆成兩個節點之後，反而更接近實際流程，也讓生成式 AI 比較容易理解前後順序。

條件本身也要寫到真的可以判斷真假，例如重要的信這種說法人可以靠經驗理解，但 AI 不知道重要到底代表什麼，如果改成主旨或內文包含特定字串，這個條件才真正有機會直接落進設計工具。

分支也是同樣的道理，成功做什麼、失敗做什麼、例外又該怎麼處理，最好各自拆開，不要全部塞進同一句描述裡。

做到這裡之後很容易產生另一個錯覺，既然一段自然語言可以讓生成式 AI 幫忙長出一個流程，那是不是只要規格寫得夠完整，就能直接得到可以使用的成品。

實際上這時候產生的內容通常還只是一個骨架。

前一天整理的七欄規格裡，Trigger、Action、Decision 很適合直接放進描述，因為它們剛好能對應觸發程序、動作與條件。這三類資訊講清楚通常已經足以讓 AI 把第一版流程搭出來，但是像 Input 缺漏時怎麼處理、Action 做到什麼程度才算成功、哪一個節點需要人工 Review，這些事情仍然要回到設計畫面逐一補上。

再往前一天談到的確定性要求就更明顯，唯一識別碼怎麼產生或者是重試之前要不要先確認前一次其實已經成功，十筆資料只完成八筆時到底算成功還是失敗，這些都已經超過單純描述流程的範圍。

生成式 AI 可以幫忙把主要節點排出來，但沒有辦法替流程設計者決定所有例外狀況。

所以用自然語言搭配生成式 AI 建立流程，最有價值的地方，還是在前面那一段。它可以先把 Trigger、Action、Condition 排出來，也省掉搜尋連接器、拖拉動作和整理版面的時間。但只要流程開始碰到例外、狀態、重試、稽核或人工確認，就還是得回到設計工具裡處理。

因為走到這一層之後要決定的已經不只是流程怎麼跑，而是當事情沒有照原本預期發生時，系統接下來到底要怎麼走。

今天可以做的一件事

最省事的做法是這一句：

把昨天那份規格整段貼進 Power Automate，讓它生成。

這就是開頭那條流程的來歷。下面兩段 prompt 換一個順序：先把規格翻譯成描述，生成之後再逐格比對。

第一段：把規格翻成生成器吃得下的描述

以下是一份流程規格。請把它翻譯成一段要貼進 Power Automate 的描述。

【流程規格】
Goal：客服信箱收到的客戶來信，自動整理成 Jira 工單
Trigger：客服信箱收到新信，且未被信箱既有過濾規則擋掉
Input：寄件信箱、主旨、內文、附件；沒有附件不擋，標註「無附件」
Decision 1：信中有描述問題或提出要求才建票；單純道謝、行銷訂閱不建
Decision 2：內文含「無法上課」或「已付款但無法使用」，
  或同一寄件信箱 24 小時內第三次來信，標為緊急
Decision 3：寄件信箱比對不到客戶名單時，標為「未知客戶」，仍然建票
Action 1：建立 Jira issue，成功判準是取得 issue key
Action 2：緊急案件即時通知客服組長，成功判準是通知送達
Output：一張 Jira issue，含客戶、分類、是否緊急、原信連結
Review Gate：標為緊急、或標為未知客戶的，建票後由人確認

請輸出三個部分：

一、描述本文（用英文撰寫，因為這項功能對英文以外的語言不保證支援）
   規則：
   - 用 When X happens, do Y 的句型開頭
   - 一句話只描述一個節點
   - 指名服務名稱（Outlook、Jira、Teams）
   - 條件寫成可以判斷真假的句子，不要用形容詞
   - 一句話裡不要放兩個分支

二、對照表
   三欄：規格的哪一項、對應描述裡的哪一句、這一句如果被忽略會怎樣

三、這段描述表達不了的項目
   列出規格裡無法靠描述傳達、必須在生成之後手動補的部分，
   並說明各自該補在哪一類設定上。不要提供替代寫法，我只要清單。

第三個部分才是這段的重點。它應該至少指出成功判準、Review Gate、以及 24 小時內第三次來信的計數這三項。這份清單先印出來，等一下要拿來對照。

第二段：生成之後逐格比對

生成完之後，把畫面上那條流程的觸發程序與每一個動作的名稱，照順序抄下來，連同你看到的條件設定，一起貼進下面這段：

以下是我用那段描述生成出來的流程節點，依照畫面上的順序抄錄。

（貼上節點名稱與條件設定）

請對照上面那份【流程規格】，逐項回答：

1. 規格裡的哪幾項在生成結果中找不到對應節點
2. 哪幾項有對應節點，但條件或參數被簡化了，簡化成什麼
3. 哪幾個節點是規格裡沒有、生成器自己加上去的

不要提供修正建議，也不要重寫描述。我要的是一張差異清單。

第三題最容易被跳過，而它往往最值得看。生成器補上去的節點通常是合理的，問題在於那是它替你做的決定，你沒有參與過。

至於前兩題的答案數量，實際跑過的那幾次，掉的項目大致落在昨天第三段留下的【尚未確定】那一欄，加上今天第一段 prompt 列出的「描述表達不了」清單。兩份清單如果能覆蓋掉大部分差異，代表規格這一步做對了；如果差異裡出現兩份清單都沒提到的東西，那是規格本身也沒想到的地方，值得記下來。

留到明天的問題

用講的把東西建出來，最迷人的地方在於它把「我到底有沒有想清楚」這個問題往後挪了。以前不會做就是不會做，畫面上一片空白，那份空白誠實得讓人不舒服。現在不會做也能先看到一條流程在跑，而它看起來的完成度，跟你想清楚的程度沒有關係。

這條流程已經在畫面上，接下來它會跑、會出錯、會被別人接手。出事的那天，你還讀得懂它嗎？

畫面上那條流程是照你說的話長出來的，包括你沒有說的那些。